Today's communication systems may include separate wireless and wireline portions, each of which may be owned and controlled by the same or different operators. Present cable network operators, such as Multiple System Operators (“MSOs”), use Data Over Cable Service Interface Specification (“DOCSIS”) networks for backhauling Internet traffic, but separate networks, including mobile networks, other DOCSIS networks, Wi-Fi networks, and radio networks have limited to no visibility into parts of the other network types. Each network type, whether DOCSIS or LTE, etc., may have separate traffic scheduling algorithms, and may experience higher latency due to internetwork visibility and communication.
FIG. 1 is a schematic illustration of a conventional upstream DOCSIS network 100. In the upstream direction, network 100 includes a Wi-Fi device 102, which communicates with a gateway 104 over a wireless communication pathway 106. Conventionally, wireless communication pathway 106 may be an 802.11ac wireless communication protocol. Gateway 104 may include, for example, a cable modem (CM) 108, or alternatively, gateway 104 is coupled with a CM 108.
Gateway 104 communicates with a cable modem termination system (CMTS) 110 over connection 112 using a DOCSIS 3.1 protocol. Connection 112 may be, for example, a coaxial cable or a fiber-optic link. CMTS 110 sends the DOCSIS 3.1 upstream traffic to a cable network 114, which may include operable communication with the Internet and/or Cloud, as well as one or more applications for utilizing the upstream data.
In operation, DOCSIS network 100 will experience latency in the upstream traffic as a result of several factors. For example, queuing delays may result primarily from traditional transfer control protocol (TCP) flows that send traffic faster than the link rate of network 100. The upstream traffic will be sent until a packet drop occurs. In such instances, the upstream traffic may be paused to let the queue drain. Such occurrences create a bottleneck link that results in poor latency performance for other applications that are sharing the bottleneck link.
Some recent Active Queue Management (AQM) techniques have been proposed to improve the traffic flow over the network, such as Proportional Integral Controller Enhanced (PIE), Controlled Delay (CoDel), Fair/Flow Queueing+CoDel (the “fq_codel” variant), Bottleneck Bandwidth and Round trip time (BBR, a congestion avoidance algorithm), Low Latency Low Loss Scalable throughput (L4S), DualQ, TCP-Prague, congestion exposure (ConEx), Data Center TCP (DCTCP), and Accurate Explicit Congestion Notification (Accurate ECN). The DOCSIS specifications have accordingly been updated to adopt the results of these various techniques as the research therefrom becomes available, and thus the buffer control in DOCSIS version 3.0 (D3.0) has achieved an order of magnitude reduction in latency under load, and the AQM in DOCSIS version 3.1 (D3.1) is achieved another order of magnitude reduction in steady-state latency under load. However, these advances have not kept pace with the increases in traffic and speed over present communication networks.
ECN, for example, is an extension of TCP/IP. ECN allows a router to send congestion signals without dropping packets, namely, by marking packets instead of dropping them. TCP congestion controls are algorithms for controlling the sending rate of network devices, and to adjust the sending rate according to available bandwidth. DCTCP is a scalable congestion control that uses slow-start and fast-recovery/fast-retransmission. AQM thus generally refers to techniques for controlling the filling levels and delays of queues. PIE is considered to be a more complex AQM that implements present and past queuing delays to calculate drop probabilities. L4S implements separation, identification, and scalable congestion control, and DualQ AQM expands upon L4S by using an ECN Capable Transport (ECT) codepoint to classify incoming packets, and then separate traffic into two different queues. One of the DualQ queues is dedicated for L4S traffic, and the other queue is dedicated for “classic” traffic. The separate queues of the DualQ AQM are useful for some latency reduction. However, it is desirable to further reduce latency while enabling deterministic latency for latency-sensitive packets, and particularly with respect to upstream traffic congestion.